(This is Part I of a two-part series. The second post in this series is: Is there a systems engineering silver bullet? Part II: (Not) Reinventing the Wheel.)
Is there a systems engineering silver bullet that ensures mission, program, or project design success? As much as we would like to believe so, unfortunately the answer is no. A related question is: Does the use of a systems engineering tool, suite of tools, or the following of Capability Maturity Model Integration-certified processes equate to success? Unfortunately, the answer to that question is no as well. So what’s a systems engineer to do?
Even though tools and processes don’t guarantee success, they do arm us as systems engineers to fight the good fight. We can apply a good process. We can search out, master, and use quality systems engineering tools. A word of caution, though. Remember—engineers engineer, but neither processes nor tools do. A good process serves as a valuable guide, and a good tool suite allows systems engineers to capture, store, and analyze large volumes of information the human brain can’t simultaneously manage. But the human engineer remains responsible for fulfilling stakeholder interests. The engineer performs an array of tasks—analysis, modeling, and simulation—that leads to a successful project delivery.
Tools are not a silver bullet, but we do need to arm ourselves with good tools. My definition of a good tool is one capable of managing a large volume of information, of performing broad-ranging consistency checking and reporting, of facilitating configuration control and promoting traceability all from a single application. We need to enable humans to innovate, and computers to process data. The key is in using the right tool for the right job.
A quick aside. I mention a single application in the paragraph above. A single application makes maintaining a consistent design more achievable, because all aspects of the design, requirements, architectures, and behavior are in an integrated environment and application. That doesn’t mean choosing an array of applications can’t work, but it adds steps that require one to migrate data among tools. Multiple applications require import/export steps that in my experience required clean up to maintain consistency and traceability. Import/export procedures also required testing with each revision of each application, often preventing migration to the latest version of tools.
So once again, we can ask the question: Will the use of a tool and application of processes guarantee success? Of course not. Success is never guaranteed, but when good engineers practice good processes, good tools make good engineers better.
We old-timers reminisce about the old days and wonder how projects like Apollo worked, because after all, the computers they had are reputed to have less computational capability than our cell phones. Yet they succeeded. So what’s the difference between then and today? The difference is between “complicated” and “complex.” A complicated system’s behavior happens in a linear, deterministic way, and we can work through the problem via brute force. In a complex system, the properties of the system emerge from the interaction (relationships) of the elements, which aren’t necessarily observable at the independent subsystem level.
Today’s systems continuously grow in magnitude, detail, and interdependence. When we evaluate a component or subsystem at the boundary, the design may be highly comprehensible, but when we integrate, an entirely new level of interactions occur that we hadn’t previously seen. To manage these ever-increasing complexities, the use of a modern tool is essential.
In adopting our modern tool, we need to take care, as we sometimes fail to step back and consider all the options. That is, we fail to perform complete due diligence when selecting tools and conducting process reviews. Often, organizations recognize a need to automate, or in general, to perform tasks better. Yet too many organizations conduct capability analyses and select good and even great tools, but still fail. Why? Because we are comfortable with how we’ve always done things, and so the older way of conducting business is replicated in the new system. As a result, we don’t perform better, we just get to the failure quicker.
What we can do is to take stock of the best of our legacy processes, discard what doesn’t work, and embrace the new, even if it means retraining how we think. How we move forward in this new environment will be the subject of Part II.
A key aspect to always remember is that tools and processes don’t replace good engineers. Good systems engineering means maintaining proficiency through education (webinars and formal classwork) and professional affiliations (INCOSE), executing quality processes (ISO), and mastering great tools (CORE and GENESYS). There are no silver bullets, but there are ways to properly arm.
Good luck, and happy engineering!
